1. Field of the Invention
The present invention pertains to telecommunications network, services, nodes, and devices, and particularly to those involved in group call services.
2. Related Art and Other Considerations
Public Land Mobile radio Network (PLMN) is a generic term for a mobile wireless network that is centrally operated and administrated by an organization and uses land-based radio frequency transmitters or base stations as network hubs. PLMNs can stand alone and interconnect with one another or connect to a fixed system such as the PSTN.
In the near future there will be an increasing traffic load on the packet switched part of the PLMNs, such as GSM/GPRS, UMTS (WCDMA) and CDMA2000. One service that utilizes packet switched bearers is referred to as Push to talk over Cellular (PoC). Push to talk over Cellular (PoC) is currently being standardized and agreed upon in an industry consortium known as the Open Mobile Alliance (OMA) forum. See, http://www.openmobilealliance.com/tech/wg_committees/poc.html and OMA PoC User Plane, OMA-UP-POC=V0—1-20041005-D, Draft Version 1.0.9 October 2004, incorporated herein by reference.
Push-to-talk over Cellular (PoC) is being developed for handsets (e.g., remote terminals) in networks such as GSM/GPRS networks, EDGE networks, UMTS, and CDMA systems. PoC is basically a voice chat for cellular telecommunication systems. PoC provides quick one-to-one or group communication, providing something like a short instant messaging service which feels like “walkie talkies”.
PoC enabled handsets will most likely be equipped with a PoC-button. The PoC button may (for example) be: a dedicated hardware button; an assigned button on a standard keypad; or, a software button used in e.g. pressure sensitive screens. When the PoC button is pressed, the handset is connected directly to another user or user group. The first releases of PoC provide half-duplex service, although full duplex may be available at a later stage.
Combinational services enrich the Circuit-Switched (CS) voice service of today, with images and video-clips. The images and/or video-clips would utilize the packet switched (PS) part of the PLMNs when being transferred from one user's client to another user's client.
Much effort and investment has been made to develop a fully packet switched solution for voice communication. Such solution is often referred to as Voice over IP (VoIP) since it is assumed that the Internet Protocol (IP) will be used to carry the media. Now this work will be reused to further enhance VoIP. It is anticipated that in the near future it will be possible to offer combinations of, for example, PoC with video and/or images, and VoIP with video and/or images, even over current deployed PLMNs.
Like a “walkie-talkie”, the voice communication in the PoC service is half-duplex, which means that media can only be sent when a PoC “client”, (e.g., remote terminal, mobile station, handset, or user equipment unit (“UE”)) is not receiving media. It is the infrastructure of PoC (e.g., a PoC server) that makes sure that the service is half-duplex by rejecting attempts of a PoC client to send while the PoC client is receiving media. One of the main reasons why half-duplex communications is preferred in PoC, is that the speech from one user can easily be multiplied by the infrastructure and sent to many users in a group (thereby enabling group communication) without the need of an expensive teleconferencing system that performs transcoding.
The PoC infrastructure controls which user that has the right to speak through a request/response mechanism known as “floor control”. Basically, in floor control a user who wishes to speak makes a request (through his/her user equipment unit (UE)) for the right to speak, and then waits for a response that either grants or denies the user's request. In accordance with early PoC proposals, the floor is granted only for talk burst on a first received basis, and no queuing of floor control messages is performed.
Floor control uses source and destination ports (in the UE and PoC servers) negotiated at establishment of a Session Initiation Protocol (SIP) session. SIP is described in such publications as: (1) Rosenberg, J. et. Al., “SIP: Session Initiation Protocol”, RFC3261, Internet Engineering Task Force, June 2002; and (2) Handley, M., Schulzrinne, H., Schooler, E. and Rosenberg, J., SIP: Session Initiation Protocol, IETF RFC 2543, 2000), both of which are incorporated herein by reference in their entirety.
PoC floor control is discussed, e.g., in the following documentation: (1) Push-to-Talk over Cellular (PoC) User Plane; Transport Protocols; PoC Release 2.0 (2004-05); (2) Push-to-Talk over Cellular (PoC) User Plane; Transport Protocols; PoC Release 1.0 (2004-10); and, OMA PoC User Plane, OMA-UP-POC=V0—1-20041005-D, Draft Version 1.0.9 October 2004, incorporated herein by reference, all of which are incorporated herein by reference in their entireties.
Among the foregoing documents, section 5.2 of Push-to-Talk over Cellular (PoC) User Plane; Transport Protocols; PoC Release 2.0 (2004-05) describes the main floor control procedure to request the access to the PoC media resource, which is called the Floor Request Procedure. The Floor Request Procedure utilize four floor control messages. The four floor control messages are shown in Table 1.
TABLE 1PoC FLOOR CONTROL MESSAGESMessageNameMessage FunctionFloorA UE requests that the Controlling PoC server shallRequestallocate the media resources to his/her device.FloorThe Controlling PoC server notifies the UE that it hasGrantbeen granted the floor and therefore has been grantedpermission to use the media resource.FloorThe Controlling PoC server notifies all UEs, except theTakenUE that has been granted the floor that the floor hasbeen granted to another UE. In the case of early sessionthe Floor Taken is also used as an indication of thebeginning of the PoC session for the terminating UE.Also the the real or anonymous identity of the user thathas been granted permission to use the media resourceis communicated in the message.FloorThe Controlling PoC server notifies a UE that it hasDenybeen denied permission to use the media resource.
In section 5.2 of Push-to-Talk over Cellular (PoC) User Plane; Transport Protocols; PoC Release 2.0 (2004-05) the transport protocol UDP is used to convey the four messages. Within UDP, the application layer protocol of RTCP is used to convey these four floor control messages. The floor control message transport mechanism may in the future be implemented using different transport and application protocols. Other examples of protocols that may be used are: the Binary Floor Control Protocol (BFCP) and the Message Session Relay Protocol (MSRP). BFCP is described in: Camarillo, G. et. Al., “The Binary Floor Control Protocol (BFCP)”, draft-ietf-xcon-bfcp-02, Internet Engineering Task Force, October 2004. MSRP is described in: Campbell, B. et. Al., “The Message Session Relay Protocol”, draft-ietf-simple-message-sessions-09, Internet Engineering Task Force, October 2004. Regardless of transport mechanism, the floor control protocol is built on a request/grant model. A Floor Request message should always be responded to by a Floor Grant, Taken or Deny message.
As indicated above, with early proposals the floor was granted only for talk burst on a first received basis, and no queuing of floor control messages was performed. Initially no meeting chair functionality or prioritizing between media types existed in the PoC infrastructure Queuing of floor requests was subsequently incorporated in OMA PoC User Plane, OMA-UP-POC=V0—1-20041005-D, Draft Version 1.0.9 October 2004.
Future evolutions of PoC likely will be true multimedia services in which voice, images, text and video may be sent. For instance, instant messaging is a candidate to be included in the next PoC standard. When mixing such media (like text, images and speech, for example) the PoC service may not have to be a strictly half-duplex service. Moreover, users involved in a PoC session (either one of the services that involves several users such as in a group talk, or only two users as in a personal PoC call) may want to communicate to the other users by either voice, text, images or through a video clip.
One problem facing future implementation of true multimedia services in PoC is that users perceive the media types differently from a delay perspective. For instance, users in a voice communication are more delay sensitive than users using a messaging service. Therefore, it would be unfortunate if a large text message were to delay voice frames in the multimedia PoC case.
The floor control of PoC today, as described, e.g., in the foregoing documentation, is strictly half-duplex. The half-duplex nature of PoC floor control means that a UE cannot send any media while receiving media. The half-duplex nature of PoC floor control makes sense for strictly voice communications, but if someone were to begin to send a large image, such action of image sending should not block the voice traffic for the session.
What is needed, therefore, and an object of the present invention, is an improved technique for handling floor request in a group call service such as PoC, for example.